✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

Thanks — re-running the gate on the current head. This is a substantial change and I've read it closely rather than skimming.

Template looks good ✓ — all nine headings present, including a real How to verify and a Risk & Scope section that names its own tradeoff.

Problem: real, but be clear about where the evidence comes from. The PR body reports no testing at all — "Static diff review and formatting only. No local test, build, typecheck, or CI command was run" and all three OS rows marked not tested. On the PR body alone this would fail the reproduction bar. It doesn't fail, because @wenshao independently built both arms and drove a live daemon A/B at this exact head against merge-base b5c7635ff9: base still running at t=942 s with the request parked, head aborting at exactly 15:00 and settling failed with one parent notification and no retry. That is an observed before/after, so I'm crediting the maintainer's measurement — not the PR body — for problem existence. Worth stating plainly, since the two are not the same thing.

Direction: aligned, and better-supported than most. #8586 is an open P2 tracking issue carrying roadmap/background-automation for exactly this. The reference agent's CHANGELOG also shows this is a recurring, shipping concern rather than a speculative one — "Fixed background agent tasks staying stuck in 'running' state when git or API calls hang during cleanup", "Fixed background tasks ... getting stuck on 'Running' after they finish or after resuming a session", and notably "Fixed background agents false-positive worker-stall detection storm after host sleep or macOS App Nap", which is the same failure mode your drift-guarded schedule() (rearm instead of firing when the event loop ran >1 s past due) is defending against. One thing to keep in view: this does add public surface — a new retryable 503 error shape over REST and JSON-RPC, and recordOnly reaching SDK consumers through emitNotificationToSdk. That's another reason a human should sign off rather than the gate.

Size: core paths are touched (packages/core/src/**, packages/*/src/tools/**, and a cross-package span over core, cli and acp-bridge). Breakdown of the +1456/−118: 1006 production lines across 21 files, 467 test lines across 3 files, 101 doc lines across 4 files. The title is fix(core):, not refactor, so there's no hard block — but 1006 production lines in core crosses the 500-line maintainer-awareness threshold and the 1000-line large-PR advisory. You're a maintainer (admin on this repo), and AGENTS.md exempts maintainer-authored PRs from the external two-tier gate, so I'm flagging this for awareness rather than treating it as an external-PR block. It still caps my confidence at Stage 3 and rules out an automatic approval, which is the gate's own rule and not a judgement on your authorship.

Approach: the mechanism is right; the packaging is what I'd question. This is two separable changes in one PR, and the body says so — "Included in this consolidated PR: runtime-generation draining and escalation for an Agent that ignores cooperative abort." The watchdog alone (a new module under agents/runtime, the event-emitter hooks, the TIMEOUT mapping, the one-shot failed + notify) delivers the entire headline value. The escalation half is what pulls in acp-bridge, Session, dispatch, and the error taxonomy — i.e. most of the review surface, and as it happens most of the open findings below. Splitting it would have made each half independently reviewable and independently revertible. Not a blocker, and I'm explicitly not asking you to re-cut a PR this deep in its review life; noting it because AGENTS.md's own guidance is that past roughly five rounds only Critical fixes should land, and this PR minted new findings in R1, R6 and R9.

Risk: Stage 1e matched — packages/cli/src/acp-integration/session/Session.ts is on the high-revert-correlation path list. So: no Stage 2 enrichment skipped, CI evidence required before any approval, and focus review attention on the Session/recycle interaction. That's precisely where finding 1 below landed.

Moving on to code review. 🔍

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 93eef769a7986f936c426cd4caac53c3f6f20b16 · re-run with @qwen-code /triage}

Code review

I wrote my own proposal before opening the diff: a small watchdog module under agents/runtime, two independent deadlines (one model/control, one per executing tool), hooked onto the existing agent event emitter, cooperative abort through the turn's AbortController, mapped onto the existing TIMEOUT terminate mode, settling once as failed with exactly one parent notification and explicitly no retry — and I would have left the abort-ignoring escalation out of that PR entirely. The PR matches that proposal on the watchdog half almost point for point, including reusing AgentTerminateMode.TIMEOUT instead of inventing a status. Where I'd have differed is the packaging, which Stage 1 already covers, and one design decision below.

Finding 1 — retainsPhysicalSlot is honored by three predicates and missed by the fourth (blocking, and it is @wenshao's §7)

The new flag is threaded into getRunningBackgroundCount(), hasRunningTasks() and pruneTerminalEntries() in background-tasks.ts, and into describeBlockingBackgroundWork() in backgroundWorkUtils.ts. It is not threaded into listUnfinalizedBackgroundAgentIds() — whose own base doc comment promises the daemon's active-work snapshot builds its holds from "the same set the registry itself would report, with no second ledger to drift out of sync", and whose predicate hasUnfinalizedTasks() deliberately shares. Session.collectActiveWorkHolds() (Session.ts:4084-4089) derives from exactly that method, and its own docstring makes the choice deliberate: "hasUnfinalizedTasks()'s predicate — not hasRunningTasks()' — backs the agent category on purpose". This PR strengthened hasRunningTasks(), the one predicate that path explicitly does not read.

The registry method has a single production caller, but that caller fans out: beyond the daemon retention path it also backs Session.isIdle() (:4061) and hasStandaloneRelocationBlockers() (:4154-4156), which gates session/cd relocation, plus the three onlyIfUnheld conditional-close reads in acpAgent.ts (:4512, :4529, :4576). So the gap is wider than detach alone.

Concretely: a failed + notified entry whose tool process is still physically alive drops out of the daemon's hold set while retainsPhysicalSlot is still true. The new failUnresponsive comment claims the retained slot keeps /clear, /resume, /branch and session switches from proceeding over live work — it does protect the TUI gates, and @wenshao measured that working. It does not protect the daemon retention path: §7 measured POST /session/S1/detach right after escalation closing the Session, the draining generation exiting, and the abort-ignoring tool's OS process disappearing before its natural end, where base holds the Session until the tool finishes. That is a destructive difference from base on a slow-but-alive tool.

This is the read-site sweep AGENTS.md asks for on every added field. Either collectActiveWorkHolds() / listUnfinalizedBackgroundAgentIds() count retained slots, or the invariant comment and the design doc say plainly that a retained slot does not survive detach and that this is the intended remedy. Both are defensible; picking one silently is not. That's the R6-6b ruling.

Finding 2 — no cumulative bound across retries, so the headline stall shape survives default provider settings (blocking, and it is @wenshao's §9)

armModel(retryDelayMs) calls clearModel() and then schedules MODEL_CONTROL_PROGRESS_TIMEOUT_MS + Math.min(retryDelayMs, MAX_RETRY_DEADLINE_EXTENSION_MS). Every MODEL_RETRY therefore restarts the base 15-minute window, making the effective deadline "15 minutes since the last retry" rather than "15 minutes without progress". With the default generationConfig.timeout of 120 s, a hung upstream is aborted and re-sent roughly every two minutes — comfortably inside the window — so the model deadline never fires. @wenshao measured head still running at t=1106 s (18.4 min), indistinguishable from base, with 12 attempts logged and the retry loop still not giving up.

Two consequences worth separating:

• The PR's stated problem — "ordinary background Agents able to wedge indefinitely and keep their Session active without a terminal result" — remains reproducible under default configuration for what the maintainer calls the most common real-world stall shape. This is not a regression (base behaves identically), so I am not calling it a break; I am calling it an unmet goal.
• MAX_RETRY_DEADLINE_EXTENSION_MS (6 h) reads like a total retry budget but only clamps a single retry's added delay. Since real retryDelayMs values are seconds to minutes, that Math.min can never bind, so the constant is effectively decorative and there is no cumulative ceiling anywhere. The design doc's "Retry delays surfaced by qwen-code extend the model deadline by at most six hours" implies a bound the implementation does not have.

The fix direction is a decision, not a diff: either extend the current window by retryDelayMs (which makes the 6 h cap a real cumulative budget and matches the doc), or keep restart semantics and correct the doc. Overlaps R6-3 / R6-6a.

Finding 3 — isChannelLive()'s rewritten contract contradicts its unchanged implementation (new this pass, should fix before merge)

bridgeTypes.ts rewrites the interface doc from "Whether an ACP channel is currently live (spawned and not dying)" to "Whether an ACP channel is active and can accept fresh workspace work … while a draining generation still owns existing sessions but cannot accept new work." But the implementation still delegates to liveChannelInfo(), which the PR only reformatted — channelInfo && !channelInfo.isDying — and isDying is now a derived getter for state === 'dying'. So isChannelLive() returns true for a draining generation, which the new doc says cannot accept fresh work. The doc now describes admissibleChannelInfo(), the genuinely new predicate, while the method it documents still reports liveness.

Behaviour is unchanged, so nothing breaks today. The problem is that this is the public contract for roughly eight production call sites — daemon-status.ts:679/716 (aggregate child-RSS numerator and denominator), routes/health.ts:92 (runtimeChannelAlive), workspace-service/index.ts:406/474/489/553/560/581/854/975 (acpChannelLive envelope field and preheat gating), plus server.ts:1314 and three sites in run-qwen-serve.ts. Those consumers want liveness; the doc now tells the next author this method means admissibility, and admitting fresh work on a true during a drain is exactly the mistake that produces a 503 the caller did not expect. Either restore the liveness wording, or move isChannelLive() onto admissibleChannelInfo() and re-audit every one of those sites — they are not interchangeable. This is adjacent to the still-open R1-36 but a different site.

Not blocking, but worth a look

• attachAgentProgressWatchdog re-implements the arm/clear/dispose/event-subscription scaffolding of attachStallWatchdog in workflow-stall.ts. The PR's stated reason — "it retries and deliberately suspends timing for every running tool" — is only half right: the retry lives in the runStallResilient wrapper, not in attachStallWatchdog itself, which just aborts and reports stalled(). The per-tool-deadline requirement does genuinely diverge from that primitive's blanket suspend (if (inFlightTools > 0) return;), so a separate module is defensible — but the two now differ in ways neither mentions (the new one has a clock-drift rearm guard, the old one does not). A cross-reference comment in each would keep them from drifting further.
• armModel() fires on every STREAM_TEXT chunk and each time does a clearTimeout, a setTimeout and an O(tools) scan. On a busy stream that is real timer churn; a stored deadline plus one timer compared against performance.now() would be cheaper. The existing WallClockWatchdog in workflow-sandbox.ts already works that way if you want a pattern to copy.
• MODEL_RETRY is emitted from two places in agent-core.ts — the new onRetry chat option and the streamEvent.type === 'retry' branch — so a single retry can emit twice. Harmless as written (re-arming is idempotent and forwardProgress is 1 s-throttled), but it is not obvious why both are needed.
• The record-only path is invisible in the interactive TUI: use-llm-stream.ts returns early on meta?.recordOnly, so a user only learns an Agent was force-settled from /tasks or the /clear gate. Already tracked as R1-9; noting it because it is the only user-facing signal for the escalation half.
• BridgeRuntimeRecyclingError is not in KNOWN_ERROR_TYPES (packages/core/src/telemetry/daemon-metrics.ts:25-47), so normalizeErrorType() buckets every occurrence as unknown in daemon.bridge.error.count instead of naming it. Small, and that allowlist is already non-exhaustive — WorkspaceDrainingError and DaemonDrainingError are absent too — so the omission may well be deliberate; but a recycle-induced 503 is exactly the event an operator would want distinguishable from a genuinely unknown bridge error.

What I checked and found sound

Worth recording, since the findings above could otherwise read as a general lack of confidence in the change:

• The watchdog attaches only inside runBackgroundTurn, reached from exactly two call sites — the fresh background launch and the resident hot continuation. The foreground path registers isBackgrounded: false and never reaches it, and workflow dispatch goes through workflow-orchestrator / workflow-stall, so the "workflow dispatch remains unchanged" claim checks out.
• isDying becoming a getter/setter over the new state field is the right call — one source of truth, and the setter's truthy-only write matches every existing set-site (there are no isDying = false assignments to break).
• The early return added to agent-headless.ts's catch block sits inside try/catch/finally, so the finally still emits FINISH, logs telemetry and calls onStop. Teardown is not skipped; the error is deliberately swallowed so a timeout surfaces as TIMEOUT rather than a throw, and the agent.ts success path was patched to match.
• The modelBatch.length === 0 early return in nonInteractiveCli.ts is placed after the splice and after emitNotificationToSdk, so record-only items still reach SDK consumers and nothing leaks in the queue.
• bridgeClient.ts validates the new recycle ext-method as owner-scoped — ownsSession, resolveEntry, and an exact reason === 'unresponsive_agent' check — before dispatching. That is the right ownership classification for a live-session-owner route.
• The drift-guarded schedule() that rearms instead of firing when the event loop ran more than a second past due is a genuinely thoughtful defence, and the reference agent's CHANGELOG shows the failure mode is real ("false-positive worker-stall detection storm after host sleep or macOS App Nap").
• Reusing AgentTerminateMode.TIMEOUT is better than it first looks: that member already existed but was effectively unreachable for agent-tool background agents, since nothing ever sets max_time_minutes for them. This PR makes a dead enum value meaningful rather than adding a new one, and correctly avoids touching the registry's TaskStatus vocabulary — which is a wire contract hard-validated in tasksSnapshot.ts:409 and mirrored into acp-bridge/src/status.ts and the TypeScript SDK, so adding a timeout status there would have been a cross-package break.

sequenceDiagram
    participant P1 as Agent turn
    participant P2 as Progress watchdog
    participant P3 as Task registry
    participant P4 as Session
    participant P5 as Bridge daemon
    participant P6 as Parent model
    P1->>P2: progress events (stream, round, tool output)
    P2->>P2: renew model or per-tool deadline
    Note over P2: fixed window elapsed with no progress
    P2->>P1: abort with AgentProgressTimeoutError
    P1->>P3: settle as TIMEOUT, persist failed
    P3->>P4: terminal notification
    P4->>P6: exactly one notification turn, no retry
    Note over P2: turn ignored the abort, 5s grace elapsed
    P2->>P3: failUnresponsive, retain physical slot
    P3->>P4: record-only notification
    P4->>P5: request runtime recycle (unresponsive_agent)
    P5->>P5: owner generation draining, spawn replacement
    Note over P5: pinned sessions stay on the old generation until they drain

Testing

This is an unattended CI run, so I did not build or execute any PR code — the review above is static, against the diff and the base tree in a read-only worktree. The evidence below is the PR's own CI, read through the API for head 93eef769a7986f936c426cd4caac53c3f6f20b16, plus one maintainer measurement I am attributing rather than adopting.

CI is settled and green. All four pull_request-event workflow runs completed successfully, and of 740 check-runs recorded on this head there are zero failures. The 14 cancelled checks are all named route and belong to the Qwen Autofix workflow on pull_request_review events — bot orchestration superseded by concurrency, not PR CI, so I am classing them as noise rather than a signal. macOS and Windows unit shards are skipped, as is the sandboxed CLI integration suite, so the green result is Linux-only.

What the green suite does not establish. None of the PR's own tests pin the three findings above, and for finding 2 that is the point: the suite passes with restart-per-retry semantics because no test asserts a cumulative bound, so a green run cannot distinguish "extends the window" from "restarts it". Not verified by me, and the reasons: the retry-loop behaviour under default provider timeout (needs a live model that hangs and retries — not observable from a diff); the detach-reaps-a-live-tool behaviour (needs a real daemon and a real abort-ignoring process); and the cancel-inside-grace rewrite (needs a real timer race).

Attribution, not evidence: @wenshao's comment on this thread reports a full A/B against merge-base b5c7635ff9 on a live daemon and in the real TUI, and reports local runs of the PR's suites green (159 core, 941 acp-bridge). That is a maintainer's measurement, not something I re-ran, and I am citing it as the source for the behavioural claims in findings 1 and 2 rather than presenting it as my own testing. The author's PR body, separately, reports no testing at all.

Sandboxed verification would settle the two behavioural gaps: @qwen-code /verify — specifically that a retrying (not merely parked) provider stall is bounded by the watchdog under default generationConfig.timeout, and that a retained physical slot actually survives POST /session/:id/detach with the tool process still alive. Neither is observable from the diff and neither is pinned by the current suite, which passes with both behaviours as they stand. A run was already triggered on this head and was still in progress when I posted (run 34759206360); its report will land in this thread. @wenshao has measured both by hand, so the value here is turning a one-off manual measurement into a repeatable A/B rather than discovering anything new.

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 93eef769a7986f936c426cd4caac53c3f6f20b16 · re-run with @qwen-code /triage}

Confidence: 3/5 — the mechanism is sound and a maintainer has already measured it working end to end, but two of the three findings are about the watchdog not covering the case it exists for, and Stage 0's core-size escalation caps this at 3/5 regardless.

Stepping back. The watchdog half of this PR is good work. I proposed essentially the same design before reading the diff and the author arrived at the same place independently — same two-deadline shape, same cooperative abort, same reuse of the existing TIMEOUT vocabulary, same refusal to enter the retry loop. The drift-guarded timer is the kind of detail that suggests someone has been bitten by host suspend before, and the reference agent's CHANGELOG confirms the failure mode is real rather than imagined. @wenshao's live-daemon A/B is the strongest evidence in this thread: base wedges, head settles at exactly 15:00, one notification, no retry. The problem is real and the fix demonstrably fixes it.

So why not approve.

My honest read is that findings 1 and 2 are not hygiene. Finding 2 means that under default provider configuration — the configuration almost every user actually runs — a hung upstream gets retried every two minutes and resets the fifteen-minute window each time, so the watchdog never fires. The maintainer measured eighteen and a half minutes with head indistinguishable from base. The PR exists to stop background Agents wedging indefinitely, and for the most common wedge shape it still does. That is not a regression and I have not called it one, but "ships a watchdog that does not watch the common case" is a substantive gap, not a nit. The MAX_RETRY_DEADLINE_EXTENSION_MS constant makes it worse by looking like a six-hour budget while being unable to bind even once.

Finding 1 is subtler and, to me, more worrying, because it is the exact failure the base code warned about in a comment. listUnfinalizedBackgroundAgentIds() says out loud that the daemon must see the same set the registry reports, "with no second ledger to drift out of sync" — and this PR introduces precisely that second ledger by teaching three predicates about retainsPhysicalSlot and not the fourth. The consumer side is explicit too: collectActiveWorkHolds() documents that it is backed by hasUnfinalizedTasks()'s predicate and not hasRunningTasks()'s, and hasRunningTasks() is the one this PR strengthened. The measured consequence is that detaching a session kills a tool process that base would have let finish — and because that one registry method has a single production caller which also backs Session.isIdle() and the session/cd relocation blockers, the gap is wider than the detach path alone. If I were maintaining this in six months, that is the one I would curse, because nothing at the call site tells you the flag is load-bearing in one registry method and invisible in the next.

Finding 3 is smaller but cheap to fix and worth fixing here rather than later: the PR rewrote a public interface doc to describe a different method than the one it documents, across roughly eight production call sites that want liveness rather than admissibility.

Now the part that is not about the code. This PR is far past the point where AGENTS.md says to stop widening it — new findings were minted in R1, R6 and R9, six Critical threads are unresolved at this head, and the author has said plainly and reasonably that they will not pick a side on §6, §7 or §9 without a ruling, because picking one silently means guessing at intent on concurrency semantics. I agree with that stance. It is also why I am not submitting a fresh request-changes review: the bot's own CHANGES_REQUESTED review (5189445584) already stands on this exact commit, the API cannot edit reviews, and stacking another would add noise without adding a gate. I am equally not dismissing it — the findings above are why it should stay up.

⏸️ Escalating to @wenshao — this needs a human call, and you are the right human. I am not approving, for two independent reasons. The policy reason: 1006 production lines across core paths trips Stage 0's maintainer-awareness threshold, which caps this run at 3/5 and forbids an automatic approval no matter how clean the review looked — noting that you are a maintainer, so this is the gate's own rule about large core changes rather than a judgement on authorship, and AGENTS.md's external-PR exemption means I am flagging for awareness rather than blocking. The substantive reason: three decisions are yours and cannot be derived from the diff.

1. Retry semantics (finding 2, your §9, overlaps R6-3 / R6-6a). Should a retry extend the current window by retryDelayMs — making the six-hour cap a real cumulative budget and matching the design doc — or keep restarting it, with the doc corrected? You called this the most common real-world stall shape, so as written the PR does not close the bug it was opened for under default settings. If the answer is "restart is fine, the retry budget bounds it", that needs saying, because your own measurement showed the retry loop still going after twelve attempts and twenty-two minutes.
2. Retained slot vs. daemon detach (finding 1, your §7, R6-6b). Is detach reaping the session and killing the still-running tool the intended remedy — in which case the invariant comment at background-tasks.ts:920-934 and the design doc should say a retained slot does not survive detach — or should collectActiveWorkHolds() count retained slots? Either is defensible; the current state has the code and its own comment disagreeing. Note the same flag also silently affects Session.isIdle() and session/cd relocation, so the ruling should say which of those the retained slot is meant to gate.
3. Cancel inside the escalation grace (your §6, R1-29 / R6-5). Should the ruling also fix what the cancel route returns and whether the parent model is told? Right now a caller gets 200 {"cancelled":true}, the registry ends at failed, and the model hears neither. Ruling only on "don't rewrite cancelled" leaves the three disagreeing.

Also unresolved and not covered by your validation: R1-36, admissibleChannelInfo() applied to workspace routes during a drain. And finding 3 above is new this pass.

Two mechanical notes. You have already APPROVED at this head (13:12:33Z); main needs two approvals and reviewDecision is still CHANGES_REQUESTED off the bot's review, so my declining to add a second approval leaves the PR where it was rather than newly blocking it. §8 is properly handled — filed as #11767 with both separable halves described and the half you answered recorded, which is the right call for something out of scope here. A /verify run was already in flight on this head when I posted; given findings 1 and 2 are exactly the claims a suite that passes with them present cannot settle, that report is worth reading against my Stage 2 note rather than as a green tick.

If the three rulings come back as "restart semantics are intended, detach reaping is intended, cancel rewrite is intended — fix the docs and comments to say so", then findings 1 and 3 collapse to documentation and I would re-run happily at 4/5. Finding 2's doc fix is cheap; the question is whether the uncovered stall shape is acceptable to ship against, and that is a product call, not a code call.

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 93eef769a7986f936c426cd4caac53c3f6f20b16 · re-run with @qwen-code /triage}

Runtime verification of PR #11270 (maintainer review)

I built a real local environment and ran this PR end-to-end against a real background Agent, rather than reviewing the diff. Reviewed at 25df3993ab205790bbb73cd5d71a42d42820edd8.

Verdict: the mechanism works and is wired correctly, but one scenario is a regression that I think blocks merge — a healthy background Agent sitting in ordinary HTTP 429 transport backoff is killed and settled as failed, permanently, with no retry. I also refute the static review's Finding 2: non-streaming tools do get their per-tool deadline.

Harness

Real dist/cli.js bundle built from the PR head, driven in a real TUI under tmux, isolated HOME, scripted OpenAI-compatible server, and a real stdio MCP server whose tool never returns. To make deadlines observable in seconds I patched only the two constants in the built bundle — 15 * 6e4 → 12e3 and 10 * 6e4 → 8e3. No logic was changed.

The merge-base arm is the same bundle with attachAgentProgressWatchdog replaced by () => {}. That is an exact behavioral revert: every other hunk in this PR is gated on getAgentProgressTimeout(signal) returning a value, which can only happen if the watchdog aborted.

A separate instrumented arm subscribes a logger to all eleven events the watchdog listens for, so the state machine's inputs are captured directly rather than inferred.

What I verified works

The whole chain holds: watchdog → AgentProgressTimeoutError on the turn controller → TIMEOUT terminateMode → registry/sidecar failed → exactly one TUI notification, no retry. The abort also propagates to the in-flight HTTP request (the fake server logs the client closing the held connection 11.9s after it was opened). Both the fresh-launch and resident-continuation wrappers are covered.

PR — settles as failed at the deadline

Merge-base — same wedge, still ticking at 60s

The run_shell_command heartbeat row matters: a silent command 3.75× longer than the tool deadline ran to completion, renewed by 14 tool_progress heartbeats. The renewal claim in the PR description is real, and there is no false-positive kill of a legitimately silent long command.

Blocking: a healthy Agent in transport backoff is killed

Scripted the subagent's provider to answer HTTP 429 with Retry-After: 45 — an ordinary, fully recoverable throttle.

+0.00s  ATTACH
+0.04s  start / round_start        -> model deadline armed
+0.21s  <429 Retry-After: 45>      transport backoff begins
        ... no watchdog event of ANY kind for the entire backoff ...
+45.40s settled: failed

• PR arm: failed, lastError: "Background agent made no model/control progress for 12000ms."
• Merge-base arm: still running at 60s, 2 retries issued, recovering exactly as designed.

PR — healthy throttled agent killed

Merge-base — survives and retries

agent-core.ts handles the retry stream event by resetting per-attempt state and emits nothing on the AgentEventEmitter, so the entire backoff is invisible to the watchdog. With the shipped constants this is not a corner case: RATE_LIMIT_RETRY_OPTIONS in llm-chat.ts is {maxRetries: 10, initialDelayMs: 60000, maxDelayMs: 300000}, so the sleep ladder reaches 1020s cumulative by retry 5 of 10 — already past the 900s deadline with five retries still to go — and retry.ts caps a single Retry-After wait at PERSISTENT_CAP_MS = 6 hours. Background Agents are the long-lived things most likely to hit a quota window, and this watchdog deliberately never retries, so one throttle blip becomes a permanently dead Agent whose notification says it made no progress while it was in fact retrying as designed.

One correction to the static review's mechanism. It states that delay() honours the abort signal, so the watchdog "actively interrupts" the backoff. That is not what happens. The abort fires at the deadline but the sleep is not interrupted — settlement tracks Retry-After exactly: Retry-After: 30 → settled at 30.4s, Retry-After: 45 → settled at 45.4s (two runs). The retry loop only observes the abort after the full sleep elapses. The outcome is the same; the timing is not.

Either emit an event from the retry branch, or pause the model deadline while a backoff is in flight.

Refuted: Finding 2 (silently-executing tools charged to the model deadline)

The static review argues that only tools streaming live output ever reach state: 'executing', so a slow MCP call is charged to the 15-minute model deadline and aborted as "no model/control progress". I had the same hypothesis from reading the code. The real run disproves it.

+0.37s  tool_call             callId=call_hang_1  name=mcp__hangsrv__hang_forever
+0.37s  tool_output_update    callId=call_hang_1     <- execution-start emit
+8.37s  tool_result           callId=call_hang_1
=> lastError: Background agent tool "mcp__hangsrv__hang_forever" made no progress for 8000ms.

agent-core.ts:2070-2084 emits a TOOL_OUTPUT_UPDATE on the → executing transition for every tool, streaming or not (it exists so the agent view can offer Ctrl+F and start the elapsed timer before first output). That is the execution-start signal the review says the event stream lacks. My MCP server sends no progress notifications at all and still got its own per-tool deadline, with the correct tool phase and tool name. The same emit also fires on awaiting_approval → executing, so the "approved tool is then unwatched" variant does not occur either.

Worth noting as a fragility rather than a bug: the tool deadline is armed by an event whose stated purpose is UI, and neither the code nor docs/design/background-agent-progress-watchdog.md says so. If that emit is ever made conditional, every tool silently loses its deadline. A comment at the onToolProgress handler naming agent-core.ts:2076 as the load-bearing arming signal would protect it.

Other measured results

The rearm heuristic roughly doubles the deadline per event-loop stall, unbounded. Driving the compiled module with the constants replaced by 9s (drift guard untouched):

rearm re-schedules a full fresh window, not the remaining time, and the rearm count is unbounded. At shipped constants that is "15 minutes, plus 15 more for every event-loop stall over one second" — in a CLI that spawns subprocesses and re-renders Ink, not exotic. Also, since expectedAt is measured with performance.now() — the same monotonic clock driving the timer — a genuine host suspend produces no measured drift and never triggers the rearm at all, so the "host suspend" half of the design-doc claim does not hold. Banking the remainder, or bounding the rearm count, would be cheap.

Prettier. Confirmed: 4 files fail prettier --check on the PR head and all 4 are clean at the merge base. The failing hunks are exactly the union-type and &&-indent reformats, all unrelated to the change. Note the PR body says "Static diff review and formatting only" — the formatting went the other way.

Typecheck / tests. tsc --noEmit -p packages/core is clean. The full packages/core/src/agents/** + tools/agent/** suite is green: 2162 passed, 6 skipped, 51 files. So nothing regresses — but v8 coverage of agent-progress-watchdog.ts under that suite is 57% statements purely incidentally (attach/dispose on background paths), with zero assertions on any watchdog behavior. No abort path is executed by any test. The sibling precedent workflow-stall.ts ships 306 lines with 362 lines of tests and takes its window as a parameter; this ships 202 lines, hardcoded, with none.

Confirmed as designed, but undocumented. Both pauses are unbounded — I drove a parked approval for a simulated 60 minutes with no timer running at all. That is probably right (an outer wall-clock limit covers it), but the design doc should say so rather than leave it looking like the original symptom relocated.

Recommendation

The problem is real, the architecture is sound, and the plumbing is genuinely careful — the typed abort reason, the .finally(disposeWatchdog) on both fork branches, and the AgentHeadless early return still running its finally are all correct. I'd like to merge this. Before that:

1. Blocking — handle transport backoff. Killing a throttled-but-healthy Agent permanently is worse than the wedge this fixes.
2. Blocking — add tests. workflow-stall.test.ts already establishes the fake-timer harness; the 429 case above is a five-line test.
3. Drop the Prettier hunks.
4. Non-blocking: bank the remainder on rearm; comment the agent-core.ts:2076 dependency; document the unbounded pauses; merge onToolProgress/onToolHeartbeat.
5. Retargeting the base at main would switch ordinary CI on — right now test, lint_and_static, build, typecheck and format never ran for this head SHA.

+0.00s  ATTACH
+0.04s  start / round_start        -> 模型期限启动
+0.21s  <429 Retry-After: 45>      传输退避开始
        ... 整个退避期间没有任何一个 watchdog 事件 ...
+45.40s 结算: failed

+0.37s  tool_call             callId=call_hang_1  name=mcp__hangsrv__hang_forever
+0.37s  tool_output_update    callId=call_hang_1     <- execution-start 事件
+8.37s  tool_result           callId=call_hang_1
=> lastError: Background agent tool "mcp__hangsrv__hang_forever" made no progress for 8000ms.

Addressed the two current-head correctness findings in 9d95f912c835. Transport retry events now suspend the model/control deadline until observable model activity resumes. Tool deadlines now start from the scheduler's actual executing transition, including a fresh transition after approval, so a silent running tool is no longer charged to the model deadline. The span classification now exempts only watchdog aborts rather than every pre-existing TIMEOUT mode, and the unrelated formatting hunks were removed. No tests were added and no local test, build, typecheck, or CI command was run.

🩺 serve daemon A/B

Built the PR base vs this PR head df0f45f, drove a fixed endpoint set against each, and diffed the JSON responses. Only fields that changed are shown.

✅ No response changes against the PR base across 12 scenario(s).

— Qwen Code · serve A/B

Qwen Code review timed out. Qwen review timed out after 21600 seconds (of the 360-minute budget). This run already used the maximum 360 minute timeout. See workflow logs.

Integrity audit of the resolved [Critical] review threads on this PR (head 93eef76), run because 36 threads were resolved with no author reply on the record.

Verified this round, highest-severity first — all four judge the cited hazard obsolete at this head, so all stay resolved:

1. R1-23 (agent-progress-watchdog.ts:217) — per-call tool deadline is now retired on that call's own terminal status, not at batch completion. Fixed in 224c7a4. Reply: fix(core): time out stalled background agents #11270 (comment)
2. R1-3 (agent-progress-watchdog.ts:174) — nested/foreground subagent progress now renews the parent's tool deadline via forwardProgress. Fixed in 224c7a4. Reply: fix(core): time out stalled background agents #11270 (comment)
3. R1-4 (agent-progress-watchdog.ts) — retry extension is now capped (6h), not bounded only by the timer ceiling. Fixed in f8fbce0. Reply: fix(core): time out stalled background agents #11270 (comment)
4. R3-1 (agent-progress-watchdog.ts) — ROUND_END suspends the deadline only on an explicit pre-wait flag. Fixed in f8fbce0. Reply: fix(core): time out stalled background agents #11270 (comment)

Nothing was re-opened. Two notes for the reviewer: the per-call settled path and the nested-progress bridge have no collocated test, and whether a 6h retry extension is right against a 15-minute liveness deadline remains the human-gated design call (it overlaps the maintainer's R3-2 condition).

Remaining 32 silent-resolved Criticals: "resolve justified, not audited this round". No code was changed.

Qwen Code review did not complete successfully. The review pipeline failed before a review could be posted. A transient error is retried automatically; if you are seeing this, retry with @qwen-code /review. See workflow logs.

Closeout round jmtz4tb6u1d — independent re-verification at head 93eef769a7 (no code change)

Verdict: needs a maintainer decision. All four unresolved Criticals were re-derived from source at this head rather than inherited from the previous round's notes. All four are REAL; none has a mechanical fix inside this round's scope ceiling (≤3 files, no new cross-package transport, no product-behaviour / public-API / semantics change). Per-thread replies carry the anchors.

Two of these produced new evidence this round that changes the shape of the decision:

• R6-6b: the suggested remediation (an unref'd fallback timer in failUnresponsive calling releaseRetainedPhysicalSlot) contradicts this PR's own documented invariant at background-tasks.ts:920-934 — "the physical slot must still be retained … otherwise getRunningBackgroundCount and hasRunningTasks() free a concurrency slot that is still occupied, and /clear, /resume, /branch and session switches all proceed over live work." A delayed auto-release does exactly that once it fires, and reset() clears the map without aborting entry.abortController, so a still-running orphan loses its only owner. The stuck gate is real (cancel() bails at :984 on the failed status failUnresponsive set at :940; pruneTerminalEntries() exempts retained entries at :1890) — but both exits cost something, so the choice is not mechanical.
• R1-36: the cheaper "refuse when liveChannelInfo() !== admissibleChannelInfo()" remediation is provably unreachable in the reported scenario, not merely ineffective. Both predicates read the same single channelInfo binding (:6318-6319 and :6321-6322), so they can only disagree when channelInfo is non-dying and not active — draining with no replacement spawned. After a recycle repoints channelInfo at the replacement both return the reference-identical object. A fan-out is feasible (aliveChannels is iterated at :2821, membership-tested at :4035); what blocks it is the partial-success contract on the workspace HTTP result and the conditional mcp_server_added broadcast.

Decisions requested

1. R6-2 — bounded total grace covering the cooperative unwind (keeping the hard force-fail), or let a late cooperative settle re-publish its real payload (incl. the worktree suffix) and skip the recycle? The second crosses agent.ts + background-tasks.ts + Session.ts and inverts terminal-outcome precedence.
2. R6-3 — should a nested run's provider-directed backoff extend the parent's tool deadline at all? If yes, retryDelayMs goes on AgentToolProgressEvent with a latch/clear rule and the MAX_RETRY_DEADLINE_EXTENSION_MS clamp re-passed through the drift re-arm closure.
3. R6-6a — may a compression side query's backoff extend a background agent's model deadline, or must compression stay maxAttempts: 1 and fail to NOOP fast? chatCompressionService.ts:749-751 argues the latter; this PR's design doc argues the former.
4. R6-6b — bounded automatic release (contradicts :920-934, can free a slot a live orphan still occupies), or user-initiated force-release in cancel() plus dropping the matching refusal in task-stop.ts?
5. R1-36 — fan out to every non-dying generation and define partial success, or reject workspace-scoped runtime-MCP mutations whenever a work-owning generation is not the active one?

Resolution-integrity audit — 32 flagged, 0 re-opened

32 resolved threads whose first comment is [Critical] end with the bot's own finding and carry no author reply. Grouped by finding id that is 20 ids, and every one of them was minted on or before 2026-09-09T11:37:45Z. The bot's two later full-diff scans (2026-09-11T09:32, 2026-09-12T04:52) re-minted only R1-36, R6-2, R6-3 and R6-6, each with explicit "Still stands at <sha>" wording — i.e. the reviewer demonstrably re-mints anything that survives a scan. Non-re-mint across two later scans is therefore the retirement evidence, and none of the 20 is a silent resolve of a still-live Critical. The resolved threads that do come from those two later rounds all carry author replies with fix SHAs (1487c0d5b6 on background-tasks.ts and bridge.ts:3808; 90e2d6f7ae on retireWhenSessionsDrain).

CI — clean, nothing PR-caused to fix

gh pr checks 11270 at this head: 22 pass / 26 skipping / 1 pending. All required suites pass — Test (ubuntu-latest, Node 22.x) 22m23s, Lint & Static 12m38s, Integration Tests (no-AK, No Sandbox) 8m49s, Serve A/B 21m30s, web-shell E2E Smoke 10m13s, Real daemon E2E, TUI parity snapshots, OpenTUI no-flicker gate, Desktop Shell (ubuntu + windows). The single pending job is review-pr, an informational review bot that does not gate. No DFSAMPLE load failures and no checkout-verification race in any log, so no infra-vs-PR attribution was needed. The skipping rows are conditional jobs (fork-PR signalling, windows/macos test shards, takeover/retry command handlers) that this run did not select.

Why /triage was not re-triggered

The standing CHANGES_REQUESTED is qwen-code-ci-bot's (2026-09-12T04:52:05Z), which is normally the cue for a standalone @qwen-code /triage. It was deliberately skipped: the head is unchanged since that scan, so a re-run would re-mint the same four findings rather than re-judge anything, and the CR is not stale — the four Criticals are live and unresolved. It clears on a code change answering one of the five decisions above, or on a maintainer override.

No push this round; head remains 93eef769a7.

Closeout round jmtzfj4451s at head 93eef769a7 (no code change this round).

Answering the two "Unresolved, please confirm" items in review 5189445584's body:

• R6-1 (approval-park charged to the 15-minute model deadline) — confirmed FIXED, resolve stands. Review 5177234081 called it "not fixed" but is pinned to 8b23578fc9 (submitted 2026-09-11T09:42Z), before 7fc6e0a4a3 landed. At head, armModel's suppression list exempts tool.state === 'approval' (packages/core/src/agents/runtime/agent-progress-watchdog.ts:107), so a parked approval carries no model timer. Detail on the thread.

• R1-29 (task_stop inside the escalation window overwritten as an unresponsive failure) — NOT fixed; I have re-opened the thread. It was resolved on 2026-09-08 citing 224c7a47b1, but 188d7b7fe3 re-admitted 'cancelled' into the guard and 1487c0d5b6 dropped the entry.notified escape. At head the guard is if (entry.status !== 'running' && entry.status !== 'cancelled') return; (packages/core/src/agents/background-tasks.ts:937-938), so the escalation rewrites a user cancellation to status='failed', re-persists it to the sidecar and notifies recordOnly — the parent model is never told. Full chain and line anchors on the thread.

Maintainer decision needed (this is the merge-blocking question, and I am deliberately not settling it myself):

188d7b7fe3 re-admitted 'cancelled' on purpose to answer R6-5 — a cancel-first path must not free a still-occupied physical slot or skip the runtime recycle — and background-tasks.test.ts:296-332 now pins that policy (expect(entry.status).toBe('failed') at :324, expect(meta.recordOnly).toBe(true) at :332). So R1-29 and R6-5 pull the same guard in opposite directions:

• narrowing the guard back to 'running' → regresses R6-5 (slot freed / recycle skipped while the execution is still alive);
• preserving status='cancelled' while still retaining the slot → requires rewriting that test to the opposite policy, which review 5177234081 explicitly said must not be treated as a resolution.

The question is which terminal record should win on the watchdog-aborts-first, task_stop-lands-inside-the-5 s-grace ordering — 'cancelled' (user intent, model must be told) or 'failed' (unresponsive, recordOnly, model not told) — given retainsPhysicalSlot = true and the recycle request are required either way. Once that is ruled, the change itself is small and I will land it with a test.

The other five unresolved threads remain escalated as human-gated and were already re-verified against this exact head, so I have not repeated those replies: R6-2, R6-3, R1-36 and R9-1 in round jmtzb8sj51m (04:55-04:56Z), and R6-6 in round jmtz4tb6u1d (01:48Z — the 03:46 review posted no new comment on that thread). With R1-29 re-opened the count is 6 unresolved of 78. CI is green on 93eef769a7; no push this round.

Local runtime validation — real qwen serve daemon + real TUI, head vs merge-base

I built both arms from source and drove this PR end to end on a live daemon (real qwen --acp child per runtime generation, real REST routes) and in the real interactive TUI, with a scenario-scripted mock OpenAI server as the model oracle. Nothing below is a unit-test stub of the watchdog: every timeout, notification, recycle and generation spawn/exit is produced by the compiled dist of each arm.

Arms: head 93eef769a7 vs merge-base b5c7635ff9 (all 21 production files reverted, the PR-added watchdog module removed; every PR marker verified absent in the base dist).
Time compression: the watchdog constants are hard-coded, so most scenarios run on a copy of the head dist with only two literals patched (MODEL_CONTROL_PROGRESS_TIMEOUT_MS 15 min → 30 s, TOOL_PROGRESS_TIMEOUT_MS 10 min → 20 s; the 5 s escalation grace and the 6 h retry cap are untouched). The unmodified 15-minute constant is exercised separately in §1.
Observables: GET /session/:id/tasks status/error at 1 Hz; every model request logged by the mock (who asked, parked/aborted, notification turns); a pid-tagged QWEN_CLI_ENTRY tee on the ACP stdio of each generation (session/new / session/prompt routing, qwen/control/session/runtime/recycle frames, generation spawn/exit codes); /health?deep=1; the real OS pid of the abort-ignoring tool.
Abort-ignoring tool: a real tools.discoveryCommand / tools.callCommand tool — DiscoveredToolInvocation.execute(_signal, …) never observes the abort signal, so this is a production code path, not fault injection.

Verdict: the watchdog, the per-tool deadlines, the approval / Monitor pauses, the restored and resident paths, and the escalation → owner-generation recycle all behave as described, and base shows the stuck behaviour the PR targets. Local test runs of the PR's own suites are green. The open maintainer decisions are real, and I measured three of them on the live daemon (§6–§8) so they can be settled with evidence rather than by reading.

1. The real 15-minute deadline (unmodified constants), head vs base

Unmodified dist on both arms; the provider request timeout is disabled (model.generationConfig.timeout: 0), so the parked subagent request has nothing but the watchdog to bound it:

(With the default provider timeout the picture is different — see §9.)

2. Model/control and per-tool deadlines (compressed head)

• Model/control stall: the subagent's model request is parked. At t=30.7 s the entry turns failed with Background agent made no model/control progress for 30000ms.; the parked request is aborted by the client; the subagent made one request (no retry); the parent receives exactly one notification turn.
• Per-tool, independent: mcp__hang__hang_forever and a ticking shell run in parallel. At t=20.9 s the Agent fails with Background agent tool "mcp__hang__hang_forever" made no progress for 20000ms. while the shell was still producing output — only the silent tool's deadline expired.
• Heartbeat control: a silent sleep 45 shell (longer than the 20 s tool deadline) completes at t=45.8 s — the 10 s shell liveness heartbeat renews its deadline, as documented.

3. Approval park — real TUI, bubbled background approval

Custom agent with approvalMode: bubble, parent in Ask permissions. The background write_file approval was parked from 08:02:02.9 until I approved it at 08:06:55.6 (4 m 53 s, on the 20 s / 30 s compressed arm) with the Agent still running and the footer showing ⚠ needs approval. After Yes, allow once the tool ran (approved.txt written), the subagent's final request went out, and the TUI printed Background agent "bubbler: probe APPROVE" completed. followed by one parent notification turn. (Note: bubbling only exists in the interactive TUI — shouldBubble requires config.isInteractive(), so daemon background Agents auto-deny instead of parking.)

4. Restored run, resident continuation, Monitor-owned wait

5. Escalation → owner-generation recycle (the consolidated half)

Head, abort-ignoring slow_probe (60 s):

• tool-start +25.2 s (20 s deadline + 5 s grace): entry failed · Background agent tool "slow_probe" made no progress for 20000ms.
• the child sends qwen/control/session/runtime/recycle {reason: "unresponsive_agent"}; a second generation spawns 36 ms later; the daemon logs runtime recycle requested … deferring channel retirement until 1 active session(s) drain.
• routing: prompts on the pinned session S1 keep going to the old generation; a fresh POST /session lands on the replacement.
• record-only: no parent notification turn and no further subagent request.
• after the tool ends and S1 is deleted, the old generation exits code=0; one generation remains.

Base, same scenario: one generation throughout, the Agent stays running for the full 60 s and then completes normally with a parent notification.

The same two paths in the real TUI

• Cooperative TIMEOUT: ● Background agent "general-purpose: probe HOLD" failed. appears in the transcript, the parent gets its notification turn, and the row shows ✖ probe HOLD ▶ 30s.
• Escalation (record-only): the footer flips to 1 task done, but no notification line is printed — the interactive TUI drops recordOnly notifications (use-llm-stream.ts returns early; already tracked as R1-9). The user only learns what happened from /tasks or the gate below.
• Retained slot gates /clear: while the abort-ignoring tool is still alive, /clear is refused with … probe DISC — still stopping (failed 36.2s). Once the tool's OS process ends (90 s), /clear succeeds. So in the TUI the retained physical slot does protect session reset — contrast with the daemon detach path in §7.

Findings / decision inputs

6. R1-29 reproduced on the live daemon — a successful cancel is silently rewritten. POST /session/:id/tasks/:taskId/cancel at tool-start +22.0 s (inside the 5 s grace after the 20 s deadline) returns 200 {"cancelled":true,"status":"cancelled"}, and the task list shows cancelled. At +25 s the escalation overwrites it to failed (watchdog error), requests the recycle, and the parent model receives no notification turn — neither the cancellation nor the failure.

So the API tells the caller one terminal state and the registry/sidecar/model end up with another (or none). Whichever way the R1-29 / R6-5 question is ruled, I'd suggest the rule also cover what the cancel route returns and whether the parent model is told.

7. The retained physical slot does not hold the daemon Session — detach reaps it and kills the still-running tool. After escalation the child's active-work holds come from listUnfinalizedBackgroundAgentIds() (running, or cancelled && !notified), so a failed + notified entry drops out even while retainsPhysicalSlot is set. Measured:

• head: POST /session/S1/detach right after escalation (tool still running) → about 1 s later, once the notification-acceptance hold releases, the Session is closed (GET → 404), the draining generation exits code=0, and the slow_probe OS process is gone before its 60 s (it never logs its end).
• base: the same detach while the Agent runs keeps the Session (activeWork:true) until the tool finishes at 60.8 s, then closes normally.

This matters for R6-6b. At the daemon level the retained slot is already released through detach/close + generation exit, which contradicts the invariant at background-tasks.ts:920-934, and on a slow-but-alive tool it is a destructive difference from base. Either that is the intended remedy, and the invariant comment/design doc should say so, or collectActiveWorkHolds() should count retained slots.

8. Second recycle while the first generation is still draining — the workspace recovers, but the second recycle is dropped. S1's escalation moves the workspace to generation 2; then an Agent in S2 on generation 2 escalates while generation 1 still drains (S1's tool holds 150 s):

• the daemon logs runtime recycling blocked recovery work; generations=…:draining…,…:draining…, and the child's recycle request is answered with JSON-RPC -32603 Internal error — not the retryable runtime_recycling shape.
• generation 2 is rolled back to active: fresh POST /session S3 and S4 both return 200 (no 503 stranding) and land on generation 2 — the generation that still hosts S2's unresponsive Agent.
• after generation 1 exits, nothing retries the recycle (Session.#recordUnresponsiveAgentNotification calls the ext-method once and only logs a warning), so generation 2 keeps taking fresh work.

This answers the triage question from 6bc80c0 (the workspace does recover), but leaves the second unresponsive Agent's generation un-recycled. Worth a follow-up issue if not in scope here.

9. With default provider settings, a silently hanging provider never trips the model/control deadline. This is the same scenario as §1 with the default generationConfig.timeout (120 s), bottom half of the §1 image. On both arms the request is aborted every ~120 s and re-sent (12 attempts between 07:53:21 and 08:15:35, and the loop had not given up). Head is still running at the last status sample, t=1106 s (18.4 min), exactly like base, and its subagent was still retrying 22 minutes after the first park when I stopped both daemons.

The only difference from §1 is the provider timeout, so the cause is the retry path: each retry emits MODEL_RETRY, and onModelRetry → armModel(retryDelayMs) clears the timer and starts a fresh 15-minute window (plus the delay). The design doc says retry delays extend the deadline, but in practice the deadline becomes "15 min since the last retry", not "15 min without progress". A hung upstream is then bounded only by the retry budget, and that budget did not stop here.

This is probably the most common real-world stall shape, so it seems worth deciding whether a retry should extend the current window by retryDelayMs instead of restarting it. It overlaps R6-3 / R6-6a.

Tests on this head

• packages/core: agent-progress-watchdog.test.ts + background-tasks.test.ts — 159 passed.
• packages/acp-bridge: bridge.test.ts — 941 passed.
• CI on 93eef769a7: 23 pass / 27 skipping (macOS/Windows unit shards skipped).

Harness notes

• tools.discoveryCommand tools are only registered when QWEN_CODE_LEGACY_MCP_BLOCKING=1: Config.initialize() passes skipDiscovery: true in the default mode, and discoverAllTools() is the only caller of the command discovery. This predates the PR (config.ts is not in the diff); I used that escape hatch for the escalation scenarios.
• The compressed arm differs from head only in the two literals above (checked with grep -n "_MS = " on the patched file).

@wenshao 谢谢这轮真实 daemon 验证。收到并逐项对齐，说明本轮巡检为什么不往这个 PR 里加代码、以及哪几项在等你裁定。

一、先确认这轮的基线变了

你的验证跑在 93eef769a7 vs merge-base b5c7635ff9，正是当前 head。你此前两次阻塞结论都落在祖先提交上，且两个 sha 都还在这个 PR 的提交列表里：

• 第 1 轮 09-07T07:17Z @ 25df3993 —— "one scenario is a regression that I think blocks merge"，即处于普通 HTTP 429 传输退避中的健康后台 Agent 被杀并永久结算成 failed。
• 第 2 轮 09-07T08:14Z @ 9baccbe5 —— "the blocking finding is not fixed — it was fixed on a code path my scenario never reaches — and the fix introduces a new, worse hole that re-opens the exact bug this PR exists to close"（你实测新 head 90s 仍 running、Agent 永久卡死，而 25df3993 是 12.04s failed）。

所以本轮以你 08:20Z 这条为准：

the watchdog, the per-tool deadlines, the approval / Monitor pauses, the restored and resident paths, and the escalation → owner-generation recycle all behave as described, and base shows the stuck behaviour the PR targets.

即机制层面 head 已经对上，剩下的都是决策而不是实现。

二、§8 已按你的建议开成独立 issue

#11767 —— 第二次 recycle 在第一个 generation 仍在 draining 时被丢弃，且没有任何重试。里面写清了两个可分离的半边（-32603 Internal error 不是可重试的 runtime_recycling 形状；Session.#recordUnresponsiveAgentNotification 只调一次、失败仅告警），也写清了你这次已经回答掉的那半：workspace 确实能恢复，S3/S4 都拿到 200、没有 503 stranding，坏的只是第二个 Agent 所在的 generation。你那张 07-second-recycle-cap.png 一并引过去了。

三、§6 / §7 / §9 在等你裁定，本轮不动代码

这三项都命中巡检的 human-gate 第①条（改并发原语语义），且这个 PR 已触发评审不收敛熔断——findings 分别在 R1（09-07T13:44Z）、R6（09-09T20:43Z）、R9（09-13T03:46Z）三轮被新 mint，所以本轮起对它停止加代码。你测出来的证据正好让这三个决策可以"凭数据定"而不是"凭读代码定"，具体请你给个方向：

§6 → 对应 R1-29（agent.ts:3889，也与 R6-2 的 5 秒宽限窗同源）
你测到 cancel 在 tool-start +22.0s（落在 20s 期限后的 5s 宽限内）返回 200 {"cancelled":true,"status":"cancelled"}，+25s 升级把它改写成 failed，而父模型两种终态都没收到通知轮。你提的问题我原样转给决策：R1-29 / R6-5 的裁定是否要同时规定 cancel 路由该返回什么、以及要不要告知父模型？如果只裁"不要改写 cancelled"而不裁通知，API 与 registry/sidecar/model 三者仍然会各说一套。

§7 → 对应 R6-6b（background-tasks.ts:920-934 的不变量）
你测到 head 上升级后立刻 detach，约 1s 后 Session 被关（GET 404）、draining generation code=0 退出、slow_probe 进程在它 60s 到期前就没了；base 上同样的 detach 会靠 activeWork:true 把 Session 撑到 60.8s 工具跑完。根因是升级后 child 的 active-work hold 来自 listUnfinalizedBackgroundAgentIds()（running，或 cancelled && !notified），于是 failed + notified 的条目即使 retainsPhysicalSlot 仍为真也会掉出去。这是个二选一，请你定：

• (a) 这就是预期补救 → 那 background-tasks.ts:920-934 的不变量注释和设计文档要改口，说明 retained slot 不阻止 detach 回收；
• (b) 不是 → collectActiveWorkHolds() 应当把 retained slot 计进去。
  在 (a)/(b) 定下来之前改任何一边都是在猜你的意图，所以本轮不动。

§9 → 与 R6-3 / R6-6a 重叠
默认 generationConfig.timeout（120s）下，两臂都是每约 120s abort 再重发（07:53:21→08:15:35 共 12 次，循环没放弃），head 在 t=1106s（18.4 分钟）仍是 running，和 base 一样。原因是每次重试发 MODEL_RETRY，onModelRetry → armModel(retryDelayMs) 会清掉定时器重开一个全新的 15 分钟窗口，于是实际语义变成"距上次重试 15 分钟"，而设计文档写的是重试延迟延长期限。请你定：重试应当把当前窗口延长 retryDelayMs，还是维持重开、但把设计文档改成与实现一致？你说这是现实中最常见的卡死形态，所以在裁定前我不会挑一边先改。

四、线程状态

6 条 unresolved（R1-29、R6-2、R6-3、R6-6、R1-36、R9-1）全部保持 unresolved，不静默 resolve——§6/§7/§9 的裁定会直接决定 R1-29 / R6-2 / R6-3 / R6-6 的收口方向，R9-1 作者侧已在 04:55:59Z 给出"REAL，但在本轮 ≤3 文件、不新增跨层字段/传输、不改并发语义或产品行为的天花板内无解，escalate"的结论，并附了逐链读当前 head 源码的因果链（agent-progress-watchdog.ts → background-tasks.ts → agent.ts）。R1-36（acp-bridge/bridge.ts:14880 的 admissibleChannelInfo() 在 drain 期间作用于替换代）你这轮没有覆盖，仍按原状留着。

本轮：不加代码、不 push、不 resolve 任何线程，只开了 #11767 和这条回复。

Round jmtzq8wyy28 — answering the "Unresolved, please confirm: R6-1" item in review 5189445584's body. (R1-29, the other confirm item, was answered on its own thread at 07:05:40Z, where it was re-opened.) No code this round.

R6-1 is confirmed present at head 93eef769a798, and it is a documentation/policy inconsistency, not a missing bound in code.

• agent-progress-watchdog.ts:103-110 — armModel returns without arming when any tracked tool is state === 'approval' or parkedOnInput === true.
• agent-progress-watchdog.ts:182-184 — sets tool.state = 'approval' with the comment "no deadline, matching direct approvals (approval waits must not cause false watchdog failures)".
• docs/design/background-agent-progress-watchdog.md:28-29 — "The relevant tool deadline is suspended while user approval is pending."

Head is internally consistent and deliberately unbounded: an approval wait suspends both the tool deadline and the model deadline, with no timeout. What conflicts is older review-guidance / test-plan text describing the approval behaviour as bounded. @wenshao's §3 measured precisely this path on the real TUI (approvalMode: bubble, parent in Ask permissions): the background write_file approval parked 4 m 53 s on the 20 s / 30 s compressed arm with the Agent still running and the footer showing needs approval, then completed normally with one parent notification turn after approval. §4's Monitor-wait rows show the same "no timeout during the wait" behaviour. So there is no observed defect to fix — only two documents to reconcile.

Reconciling them means deciding whether an approval wait should carry a bound at all, which is a timeout-policy decision. @doudouOUC's review 5177234081 says the same from the reviewer side: "The documented bounded approval behavior conflicts with older review guidance/test-plan text … I am not inventing another timeout policy here." Not picking a side; R6-1 stays unresolved.

Queue status at this head, for the record. All 6 unresolved Criticals (R1-29, R6-2, R6-3, R6-6, R1-36, R9-1) plus R6-1 were re-verified against the live tree this round — background-tasks.ts:937-938 (cancel admitted by the escalation guard), :943 + :1749-1753 (retainsPhysicalSlot latched before emitNotification, whose first statement is if (entry.notified) return;, with Session.ts:10168 the recycle's only production trigger), agent-progress-watchdog.ts:19/99-125, agent.ts:1477-1485, llm-chat.ts:564 vs TryCompressOptions at :588 (no onRetry), bridge.ts:14699/14821/14877 (workspace routes on admissibleChannelInfo()). All REAL, all waiting on a ruling. CI is green: Test (ubuntu-latest, Node 22.x), Lint & Static, Integration Tests (no-AK, No Sandbox), Serve A/B, Real daemon E2E / Java 11, TUI parity snapshots, OpenTUI no-flicker gate all pass; macOS/Windows unit shards and Integration Tests (CLI, No Sandbox) are skipped.

reviewDecision=CHANGES_REQUESTED comes solely from the bot's review 5189445584 at this same head — doudouOUC's 5177234081 is state COMMENTED, so it does not carry the gate. There are 0 approvals and 4 outstanding review requests (wenshao, tanzhenxin, LaZzyMan, qqqys), so the PR is human-gated whatever this queue does.

Deliberately not pushing code this round. Review 5189445584's "Mechanism health" paragraph states the round withheld its incremental anchor and the round it recovered to had none either, so the next review re-reads the whole diff. A commit here buys a full re-review of a +1456/-118 diff on a PR that minted new findings in R1, R6 and R9, and closes none of the 6: §6/§7/§9 need @wenshao's ruling (requested 09:20:35Z, no reply yet), and R1-36 needs a routing decision for workspace-scoped MCP mutations during a drain that no measurement has covered. §8 was filed as #11767.

@qwen-code /triage

Sandboxed verification: ❌ not passed — findings reported (agent verdict) - workflow run

Ran the PR in an isolated, token-free container: A/B against the base build, mock-free harness assertions, targeted gates. Advisory evidence for human reviewers — not a review, an approval, or a CI check.

Scripted assertions: 43 passed · 0 failed · 43 total

Flakiness gate: ✅ 3 changed test file(s) x 5 identical rounds, no divergence

node tmp/pr11270-verify-20260913-132919/harness-watchdog-ab.mjs \
  --tree /__w/qwen-code/qwen-code --arm head --only approval-park

The relevant tool deadline is suspended while user approval is pending. The
model deadline is suspended only after a no-tool round enters a Monitor-owned
external-input wait, and resumes when input arrives.

registry.setNotificationCallback((displayText, modelText, meta) => {
  if (meta?.recordOnly) return;

rounds=5 files=3 skipped=0
file packages/acp-bridge/src/bridge.test.ts: (cd packages/acp-bridge) npx --no-install vitest run ./src/bridge.test.ts
file packages/core/src/agents/background-tasks.test.ts: (cd packages/core) npx --no-install vitest run ./src/agents/background-tasks.test.ts
file packages/core/src/agents/runtime/agent-progress-watchdog.test.ts: (cd packages/core) npx --no-install vitest run ./src/agents/runtime/agent-progress-watchdog.test.ts


per-file results (P=pass F=fail I=infra-exit, one letter per run):
  packages/acp-bridge/src/bridge.test.ts: PPPPP
  packages/core/src/agents/background-tasks.test.ts: PPPPP
  packages/core/src/agents/runtime/agent-progress-watchdog.test.ts: PPPPP

verdict: pass
summary: 3 changed test file(s) x 5 identical rounds, no divergence

--- per-invocation detail (full copy in the artifact) ---
round 1 · packages/acp-bridge/src/bridge.test.ts: P (exit 0)
round 1 · packages/core/src/agents/background-tasks.test.ts: P (exit 0)
round 1 · packages/core/src/agents/runtime/agent-progress-watchdog.test.ts: P (exit 0)
round 2 · packages/acp-bridge/src/bridge.test.ts: P (exit 0)
round 2 · packages/core/src/agents/background-tasks.test.ts: P (exit 0)
round 2 · packages/core/src/agents/runtime/agent-progress-watchdog.test.ts: P (exit 0)
round 3 · packages/acp-bridge/src/bridge.test.ts: P (exit 0)
round 3 · packages/core/src/agents/background-tasks.test.ts: P (exit 0)
round 3 · packages/core/src/agents/runtime/agent-progress-watchdog.test.ts: P (exit 0)
round 4 · packages/acp-bridge/src/bridge.test.ts: P (exit 0)
round 4 · packages/core/src/agents/background-tasks.test.ts: P (exit 0)
round 4 · packages/core/src/agents/runtime/agent-progress-watchdog.test.ts: P (exit 0)
round 5 · packages/acp-bridge/src/bridge.test.ts: P (exit 0)
round 5 · packages/core/src/agents/background-tasks.test.ts: P (exit 0)
round 5 · packages/core/src/agents/runtime/agent-progress-watchdog.test.ts: P (exit 0)

Evidence images

Harness scripts and raw logs are in the workflow run artifacts (7-day retention).

— Qwen Code · sandboxed verification

Triage re-run completed without a new review.

The bot already has a review of its own on 93eef769a7986f936c426cd4caac53c3f6f20b16, which still stands.

机器人在 93eef769a7986f936c426cd4caac53c3f6f20b16 上已有自己的评审，且仍然有效。

The stage comments above were updated with the latest result. View workflow run.

上方各阶段评论已更新为最新结果。查看工作流运行。

巡检轮 jmu07e78o2w —— head 93eef769a798，本轮不改代码、不推送

@wenshao 谢谢 13:12:33Z 的 APPROVED。先把本轮结论说清楚：你的 approve 的 review body 是空的（review 5190785254），所以它没有对 §6 / §7 / §9 给出任何文字裁定。我不能把空 body 读成「按现状合入、残余风险已接受」——那会变成替你做决定，然后把 6 个争议中的 Critical 线程 resolve 掉。本轮 6 个线程全部保持 unresolved，每个都已回帖写明各自撞的是哪一道闸。

一、你 approve 时，这三个问题按你自己的文字仍然是开着的

你在 08:20:18Z 的验证 里的总判语：

The open maintainer decisions are real, and I measured three of them on the live daemon (§6–§8) so they can be settled with evidence rather than by reading.

即「测量是为了便于裁定」，不是裁定。分项也都是将来时／二选一：

• §6：「Whichever way the R1-29 / R6-5 question is ruled, I'd suggest the rule also cover what the cancel route returns and whether the parent model is told.」
• §7：「Either that is the intended remedy, and the invariant comment/design doc should say so, or collectActiveWorkHolds() should count retained slots.」
• §9：「it seems worth deciding whether a retry should extend the current window by retryDelayMs instead of restarting it.」

所以只差你三句话就能全部解锁：

1. §6（R1-29 vs R6-5）：cancel 与 watchdog 升级竞争时终态以哪个为准？另外 cancel 路由返回什么、要不要通知父模型。（这一项还叠着 @doudouOUC R6-5 的相反要求，background-tasks.test.ts:296-332 把现行政策钉住了，改任何一边都要先有裁定。）
2. §7（R6-6b）：retained slot 的权威口径是「detach/关会话即释放 → 改 background-tasks.ts:920-934 的不变量注释与设计文档」，还是「collectActiveWorkHolds() 必须计入 retained slot」？
3. §9（R6-3）：retry 是「延长当前窗口 + 累计 6h 上限」（则 docs/design/background-agent-progress-watchdog.md:22-23 成立），还是「保持 restart」（则那句要改写成"距上次 surfaced retry 15 分钟"）？改文档和改代码分别等于选边，所以我两边都没动。

二、本轮对 6 个线程都重读了源码，全部 REAL，全部在闸门之外

不是沿用上轮摘要，逐条重跑的关键证据：

• background-tasks.ts:937-938 守卫仍是 status ∈ {running, cancelled}，:943 仍 latch retainsPhysicalSlot = true，:920-934 的不变量注释逐字仍在；
• releaseRetainedPhysicalSlot 全仓非 dist 只有 2 个调用点（agent.ts:3916、background-agent-resume.ts:1437），都在 run body 的 .finally 里；cancel() 在 :984 因 status !== 'running' 直接 bail，所以用户再 cancel 也放不掉；
• sessionRuntimeRecycle 全仓非 dist 恰好 3 个 src 命中：常量（status.ts:195）、子端 handler（bridgeClient.ts:1340）、唯一发送点 Session.ts:10168；而 emitNotification 在 :1753 的 if (entry.notified) return; 会在 cancel 抢先后把 recordOnly 通知连同这次 recycle 一起吞掉；
• agent-progress-watchdog.ts:99-125 的 armModel 确实先无条件 clearModel() 再排 MODEL_CONTROL_PROGRESS_TIMEOUT_MS + Math.min(retryDelayMs, MAX_RETRY_DEADLINE_EXTENSION_MS)——restart 而非 extend，:20 的 6h 只夹单次 delay，不累计；
• agent.ts:1477-1485 的 forwardProgress 确实零参、1/s 节流、patch {}，MODEL_RETRY 就绑在它上面。

顺带更正上轮我在这条线程上说错的一句话：我曾写「nesting 修复需要跨包事件 schema 变更」。不对——AgentToolProgressEvent 是 core 内部的（定义 agent-events.ts:181，只有 agent-progress-watchdog.ts:172 消费、agent-core.ts:2111/2200/2220 发出，cli / acp-bridge 都不消费）。正确的反对理由更窄但同样成立：要把 delay 从嵌套 MODEL_RETRY 送到父 watchdog，得跨 4 个文件 2 层，超出本轮 ≤3 文件上限，而且在 extend-vs-restart 定下来之前它没有意义。

三、合并闸门的实际算术（这是本轮真正卡住的地方）

mergeable: MERGEABLE   mergeStateStatus: BLOCKED   reviewDecision: CHANGES_REQUESTED
  wenshao          APPROVED           @ 93eef769a7   2026-09-13T13:12:33Z
  qwen-code-ci-bot CHANGES_REQUESTED  @ 93eef769a7   2026-09-13T03:46:16Z
  doudouOUC        COMMENTED

你的 APPROVED 和机器人的 CHANGES_REQUESTED 落在同一个 head 上。你 13:12:50Z 发的 /triage 已经跑过，13:49:31Z 的 stage=rerun-summary 明确说「机器人在 93eef769a798 上已有自己的评审，且仍然有效」——所以 triage 无法自清它，本轮也没有再发 /triage 或 /review（同一 head 上再触发只会铸造新发现）。

因此剩下的都是人类杠杆：要么由维护者 dismiss 机器人在该 head 上的 CR，要么 admin merge，要么给出上面三条裁定让我落代码。按 main 的 ruleset，这个 PR 还需要第二票 + /packages/core/ 的 CODEOWNER 票，光靠现有 1 票也不够——这点一并写出来，避免下一轮巡检误判成「只等机器人」。

本轮：0 次 push，0 个线程 resolve，worktree 保留在 93eef769a798 供下一轮接手。

Round jmu1zp0la5i — re-verification at the post-merge head 61550c3d579e.

The head moved from 93eef769a7 this round via two commits from the conflict-resolution patrol: d4002a5486 (merge origin/main) and 61550c3d57 (keep the record-only background end-turn emission type-correct after that merge took main's two-argument #emitBackgroundNotificationEndTurn signature).

All six unresolved [Critical] threads were re-checked against this head. The merge moved line anchors but changed no cited semantics:

• background-tasks.ts guard is still if (entry.status !== 'running' && entry.status !== 'cancelled') return; — now at :856 / :913 / :948 (was :937-938), with retainsPhysicalSlot = true at :953 and emitNotification(entry, true) at :963.
• UNRESPONSIVE_ABORT_GRACE_MS = 5_000 unchanged (agent-progress-watchdog.ts:19), still armed from abort().
• forwardProgress is still zero-arity and patches {} (agent.ts:1477-1485), so nothing about a nested run's unwind crosses the nesting boundary.
• In the cited file set only packages/core/src/agents/background-tasks.ts (13 lines) and packages/acp-bridge/src/bridge.ts changed, both from the main merge.

Verdicts therefore do not move: all six findings remain REAL and all six remain decisions this PR cannot settle by itself. The decisions owed are unchanged — (a) who owns the terminal record when failUnresponsive has already published status='failed' and a cooperative settle lands late (R6-2 / R6-3 / R9-1), (b) cancel-versus-watchdog terminal precedence for a task_stop landing inside the 5 s grace (R1-29), (c) whether a nested run's provider-directed retry backoff may extend the parent's tool deadline (R6-3 / R6-6).

One new administrative fact: @wenshao's APPROVED review at 93eef769a7 (5190785254) is now DISMISSED, because this head moved after it. The PR currently carries no live maintainer approval, and the review body it carried was empty, so it adjudicated nothing textually. His review has been re-requested — his §6–§8 live-daemon measurements are precisely the evidence this ruling was meant to be settled with.

No code change this round.

Resolution-integrity audit at head 5ecb509858. No code change from this; recording it because "72 of 78 threads resolved" overstates how much of this PR is documented as closed.

Counting resolved threads misleads here: the bot re-posts the same finding id every round ("Still stands at 85c1c2a2…"), so 46 single-comment resolved threads collapse to 34 distinct [Critical] findings. Per distinct finding, judged on its newest thread and cross-checked against all its siblings:

• 6 unresolved / parked — R1-29, R1-36, R6-2, R6-3, R6-6, R9-1. The known design-gated set, untouched, awaiting the ruling on watchdog/abort semantics.
• 9 properly closed — author reply citing a fix SHA or an explicit decline: R1-2, R1-3, R1-23, R4-1, R6-1, R6-4, R7-1, R8-1, R8-2.
• 4 closed with the reply on a sibling thread — R1-25 (reply on PRRT_kwDOPB-92c6f7x4R, cites 224c7a47b1), R1-4, R3-1, R4-5. Not silent, just filed elsewhere.
• 15 resolved with no author reply on any thread of that finding — the thread's only comment is the bot's own [Critical]: